Transactional and Non-transactional Data |
|
Using Process Platform, you can design XForms for use in an integrated environment, where multiple web applications display live data and that supports integration and communication between various applications. As compared to standard HTML applications, web applications render data from various backend sources and constantly synchronize with the server to update to the latest, live data.
XForms is capable of rendering data in two modes:
- Transactional data
- Non-transactional data
These data can be rendered through Web services (such as Process Platform Web service operations or external Web services) and process API.
Transactional Data
Data that confirms to the Process Platform protocol is classified as Transactional Data. Each data object in Transactional data represents an object that can be used for transactions such as creating, editing, and synchronizing with the backend.
The following sample illustrates the transactional data protocol in Process Platform:
<tuple>
<old>
<Employees>
<EmployeeID>1</EmployeeID>
</Employees>
</old>
</tuple>
In case of Transactional data, each data object (such as 'Employees' in the above sample) is wrapped in a <tuple> protocol, which is a Process Platform standard, and contains the state of the transactional object. The following are some transaction formats used in Process Platform:
Format |
Description |
|---|---|
<tuple> <old>...</old> </tuple> |
This format is used when data is retrieved from backend. |
<tuple> <new>...</new> </tuple> |
This format is used when data is created in the client. If the format also carries thesync_idattribute, it denotes that the data is yet to be synchronized with the backend. |
<tuple> <old>...</old> <new>...</new> </tuple> |
This format is used when data is updated in the server. If the format also carries thesync_idattribute, it denotes that the data is yet to be updated to the backend. |
Transactional data provides the following advantages:
- Using transactional data, it is possible do all transactions such as creation, update, deletion, and synchronization of records from the backend. Any change in the data is recorded in the above-mentioned formats.
- While closing a form, the application displays prompts containing various options to save the data.
- In cases where a large number of records (business objects) are available, you can specify a 'cursor' or iteration size to indicate the number of records to be retrieved from the backend. For information, see Generation of Layouts from Methods.
- The pagination feature is supported for transactional data. By specifying a 'cursor', it is possible to retrieve data in batches and paginate the XForm batch-wise.
Note:
The pagination feature enables you to access data in a Table control. However, the manner in which rows display in the Table control varies according to the kind of model rendered in it. For a transactional model, the table view contains a fixed set of rows, and empty rows are displayed if number of rows exceed the available data. For a non-transactional model, the table view does not contain a fixed set of rows, and no empty rows are displayed if data is not available.
Non-transactional Data
Data that does not confirm to the Process Platform standard protocol is referred to as Non-transactional Data. Non-transactional data can be any of the following:
- Data from Java Call services
- Data from an external Web service
- Any custom data (such as XML data)
The following sample illustrates non-transactional data:
<items>
<item>
<id/> ... </item>
<item>
<id/> ... </item>
</items>
This model is rendered in the same manner as Transactional Data. Also, changes made to the data are tracked internally, such that you can insert, delete, and modify data in the client. However, synchronization and saving data to the backend is not possible.
Non-transactional data has the following characteristics:
- While it is possible to modify data in the client, the changes cannot be saved to the backend.
- When an XForm is closed, no prompts are displayed to save the data.
- It is not possible to define a cursor or iteration size to display records in batches.
- The pagination feature is supported for Non-transactional data. The pagination bar is enabled if the number of data objects exceed the height of the table.
Note:
The pagination feature enables you to access data in a Table control. However, the manner in which rows display in the Table control varies according to the kind of model rendered in it. For a transactional model, the table view contains a fixed set of rows, and empty rows are displayed if number of rows exceed the available data. For a non-transactional model, the table view does not contain a fixed set of rows, and no empty rows are displayed if data is not available.
Note:
You can display non-transactional data in a Table control by specifying the XPath of the data, for example response/methodName/businessObject. Here, data from each businessObject node will be displayed in a separate row in the table.
Binding data to data models
In case of Process Platform Web services or external Web services, XForms automatically generates the user interface and binds data to respective controls. Depending on the data model used, the following types of models are created:
- Transactional Model: This model is generated in case of transactional data. This model accepts the Process Platform Web service operations (for Next and Previous) optionally.
- Non-transactional Model: This model is generated in case of non-transactional data and renders non-transactional data only.
While dragging and dropping a Web service operation to add it to an XForm, XForms automatically assigns the model type, binds the HTML controls to specific references from the data objects, and renders data accordingly. For information about data binding and setting references, see Binding Data to Controls. For information about referencing data, see Referencing Transactional and Non-transactional Data.